1. The Field of the Invention
The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More particularly, the present invention relates to techniques for transmission of message fragments between Object Request Brokers operating in distributed object oriented environments.
2. The Relevant Art
Object oriented programming methodologies have received increasing attention over the past several years in response to the increasing tendency for software developed using traditional programming methods to be delivered late and over budget. One problem with traditional programming techniques stems from the emphasis placed on procedural models and “linear” code that often is extremely difficult to design and maintain. Generally, large programs created using traditional methods are “brittle.” That is, even small changes to isolated elements of the program can affect all elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on pairing data and the procedures that act on it; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition, objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence, changes to the data and/or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, since changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of “tried and true” objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
The object metaphor in distributed systems is a useful technique as it separates the object's interface from its implementation; thus allowing software designers to take advantage of the functionalities of various objects available to them without having to worry about the details of the object's implementation. The programmer need only be aware of the object's interface. In addition, object oriented distributed systems allow for multiple implementations of a single interface, which interface may reside on different computing platforms that have been connected through a network. Thus, a programmer working on one machine of a network may make a call to an object about which the programmer has no detailed knowledge with the confidence that at the appropriate time that the remote object will be accessed and return its data so that the programmer's code will function properly. Such a system thus maximizes the inherent advantages of object oriented methodologies by taking full advantage of their modularity and encapsulation.
Attempts to provide such facilities have been made using object oriented distributed systems that are based upon a client-server model, in which object-servers provide interfaces to clients that make requests of the object-servers. Typically, in such systems these servers are objects consisting of data and associated methods. The clients obtain access to the functionalities of the object-servers by executing calls on them, which calls are mediated by the distributed system. When the object-server receives the call, it executes the appropriate method and transmits the result back to the object-client. The client and object-server communicate through an Object Request Broker (ORB) that is used to locate the various distributed objects and establish communications there between. The Object Request Broker enables objects to transparently make and receive requests and responses in a distributed environment.
FIG. 1A illustrates a request 10 being sent by a client 12 to an object implementation through an Object Request Broker 16. The client can be defined as an entity that wishes to perform an operation on an object. The object implementation can be defined as the code and data that actually implements the object. The Object Request Broker is responsible for all the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect that is not reflected in the object interface. More details about the Object Request Broker can be found in the “Common Object Request Broker: Architecture and Specification: CORBA 2.4.1”, November, 2000, which is hereby incorporated herein by reference.
As described in the Common Object Request Broker Architecture and Specification, General Inter-ORB protocol (GIOP) specifies formats for messages that are exchanged between inter-operating ORBs. FIG. 1B illustrates a first and second Object Request Broker and 52 exchanging messages. For example, the first Object Request Broker 50 can operate in client 54 and send messages to and receive messages from the second Object Request Broker 52 operating in a server 56. As is known those skilled in the art, in some situations, it is desirable to fragment messages that are exchanged between inter-operating ORBs. In other words, there is a need to fragment a message (original message) into two or more sub-messages. The original message typically includes a header and data. The corresponding fragments can also include headers and data portions which collectively represent the data in the original message.
It is often necessary to know the corresponding position of a given data byte in one of the sub-messages with respect to its position in the original message. One reason why this may be necessary is that there may be a reference to data in the original message rather than another copy of data. Since it may be necessary to know the location of a data byte with respect to its location in the original message, some conventional techniques wait until all the fragments have been constructed before any of the data fragments are transferred. However, this approach is grossly inefficient and may cause delays in data transmission between ORBs. To avoid such pitfalls, some recent techniques have been developed to allow for more efficient transmission of messages. However, these techniques put certain constraints on the transmission of data fragments. For example, the fragment header and/or fragment data sizes need to be of the same size for these techniques to work properly. In addition to the constraints, a significant amount of bookkeeping and many computations are often necessary since the conventional techniques require keeping track of several variables (e.g., number of fragments constructed, total number of bytes, etc.).
Accordingly, there is a need for techniques to facilitate transmission of message fragments in distributed object oriented environments.